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A d e vic e and a m e thod for proc e ss i ng e v e nts and act i ons 



Th e present i nvont i on Description 

A Device and a Method for Processing Events and Actions 
Priority Statement 

This application is the National Stage, filed under 

35 U.S.C. § 371, of International Application No. 
PCT/EP2005/050620 having an International Filing Date of 
February 1 1 , 2005, and published August 25, 2005, as 
International Publication No. WO 2005/078611 A1. Applicants 
claim benefit of priority under 35 U.S.C. § 1 19(a) and § 365(b) of 
European Patent Application No. 04103665.8 filed July 29, 2004. 
This application is a continuation-in-part of U.S. Patent 
Application Serial No. 10/779,343 filed February 12, 2004, for 
which Applicants claim benefit of priority under 35 U.S.C. § 120 
and § 365(c). 
Technical Field 

This disclosure relates to a device operating as a 
finite state machine and provided for processing events and 
actions relating to at least one object to be trav elle d moved 
between an initial and a final state, said- the device comprising a 
processing member connected to a memory. Th e inv e nt i on This 
disclosure also relates to a method for processing events and 
actions. 

Such a Background 

One device and process afe for processing events 
and actions is, for example^ known as IBM FlexFlow (trademark 
of IBM), which is a workflow system developed by IBM for 



interactive i nt e rnot lnternet applications.. It is a state machine 
based workflow system, which formally describes business 
processes with state charts.. The FlexFlow system uses these 
descriptions to directly control the execution of e-commerce 
applications. Floxflow FlexFlow has a visual modol li ng modeling 
tool to design and modify business process state diagrams.^ The 
visual tool generates an XML representation of the process.. This 
XML presentation is compiled and loaded into the FlexFlow 
database used by the FlexFlow engine.. For FlexFlow, events 
are incoming messages and actions corresponding to tasks 
which are executed at the level of the application server. F le xflow 
FlexFlow has been integrated in IBM's WebSphere Commerce 
suites to build web-applications. 

The prob l em of th e pr i or art d e vic e and m e thod i s that tho 
reality of processing events and actions is mefe-complex. The- With the 
FlexFlow system, the way to capture transition events is not 
straightforward in a distributed environment^ Indeed, events are 
triggered at different places, by different people and by different 
systems.. Not all events are always properly generated and they do not 
always occur in the correct order.. Most systems have difficulties to cope 
with this situation... Workflow systems, which are used to automate 
business processes, are not designed for handling such an arbitrary 
sequence of events._ Transitions in workflow systems are "explicit" 
because they lack the state pattern, where 
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transitions are "implicit".. Workflow systems usually 
expect to receive events in a particular well-determined 
sequence with explicit "wait states" until an event can occur.. As 
long as the expected event does not occur, all other events are 
queued and the process stops. 

For example, in the case of the package delivery, 
events can originate from different sources-: 

• a shipping application used in a warehouse; 

• scanners used in the warehouse; 

• handheld scanners used by the courier 

drivers; 

• scanners used at the drop-off location; 

• timer triggers in the central system^. 

All these sources are distributed over a wide geographic area 
and will typically communicate with the central system over the 
Internet, with its imperfection. 

In reality it is important to make a distinction between 
events and transitions, because not all events may necessarily trigger a 
state transition._ At the time at which events are received by the central 
system, they might indeed be obsolete, and the object to which the event 
relates, might already be in a further state._ The system needs thus to 
react differently on events based on the current state of the relevant 
object._ In the example of the package delivery one could imagine that 
there is an action linked to the transition "In transit -> delivered to 
location" which consists in notifying the recipient via a messaging 
system.. The event, which triggers this transition, would be a scan event 
in a drop-off location.^ For whatever reason the event may be delayed, 
for instance because the scanner cannot synchronise. synchronize. 
However, the recipient may actually see his package and collect it 
because he or she is visiting the location.^ Through a phone call, some 
operator in a service c e ntr e center may update the status of the package 
as "Delivered to user^/^ Subsequently, if the scanner finally manages to 
svnohroniso svnchronize . the central system should not react on this 
event in the same way as if the state of the package 
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„would be ("In Transit")., As the current state is 

"Delivered to user" there is no need to notify the end user. 

It i s an obi o ct of tho Summary of the Invention 

The present inv e ntion to cope w i th disclosure 

addresses this complexity by providing a device and a method, 

which enable to mod i fy th e b e hav i ou r modification of the behavior 

of the objects by adding new type of events, new states and new 

actions according to the evolution of the business processes and 

systems generating the events._ The disclosed device or method 

accord i ng to the invent i on should allow to branch branching to 

anywhere in the process at any time in such a manner as to 

process events immediately, without having to queue. 

Th e dev i ce or m e thod accord i ng to th e i nv e nt i on 

has b ee n d e v el op e d to The disclosed embodiments address 

problems of real time supply chain event management, due to the 

specific nature of supply chain processes. I t h a s b ee n bui l t in such 

a way as to The disclosed embodiments may solve real-time 

event-driven business process management problems where the 

business object to be monitored and controlled can be 

modol l od modeled by a finite state machine. 

For th i s purpos e a d e vice accord i ng to th e pr e s e nt i nv e nt i on 

i s charact e r i s e d i n th a t sa i d ln one aspect, initial and final stat e states are 

integrated into at least one event-state-action diagram defining said-the 

finite state machine, sai4- the memory having an input connected to a 

state engine editor and being provided for storing said the diagram , sa i d . 

The state engine editor hav i ng has an input for receiving object data, 

identifying said- the object and said- the initial and final state , said . The 

object data compr i s i ng include a first set of states, a second set of events 

and a third set of actionsT-said- . The third set compr i s i ng includes a first 

sub-set of processing actions, a second sub-set of timed actions 

provided to initiate each time at least one predetermined action of said 

the first sub-set after a predetermined time period has lapsed and a third 

sub-set of transition actions , sa i d . The state engine editor b e ing is 

provided for forming said- the diagram by matrix-wise structuring saidthe 

states of sa i d the first set and said- the events of sa i d the second set in 
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order to create at positions within s a id the matrix a state-event 
combinations-said- . The state engine editor 
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bemg- is further provided for attributing to at least 
one state-event combination at least one of said- the actions of 
said- the third seVsaid -. The processing member havmg- has an 
input for receiving event-messages and bei«g-is_provided for 
converting a received event-message into one of said-the events 
of said -the second setr-said- . The processing member b ei ng is 
also provided for monitoring saidthe states in order to 
r e cogn i so recognize an actual state for said- the object and for 
selecting within said the state diagram upon receipt of one of 
said- the event-messages a position within said- the diagram 
corresponding to sa i d the actual state and said -the event 
obtained by said the convertings-said -. The processing member 
b e ing is further provided for retrieving said- the actions located at 
sa i d the selected position and for supplying said -the retrieved 
actions to an action dispatcher in order to execute said-the 
retrieved action^said -. The action dispatcher compr i sing includes 
for each action of said- the t hird set an execution routine provided 
for controlling said -the execution of said- the action. 

The use of an event-state-action diagram defined in 
a finite state machine enables to work working with deterministic 
finite state machines thereby imposing a single transition for a 
state-event combination.. The matrix organ i sat i on organization 
not only permits to e stab li sh establishing a combination between 
the events and the states^ but also to attr i but e attributes actions 
to such a combination.. Not only does this prov i d e s provide an 
operational flexibility, but also it_enables to add adding events 
and states without deviating from the diagram concept.. Since 
the actions can be processing actions as well as timed or 
transition actions, a large flexibility is offered.. Moreover, the 
timed actions allow the finite state machine to reach a 
subsequent or final state even if some expected events are not 
received or not received at an expected time.. The use of event- 
state-action diagrams further gives the processing member the 
possibility to process event-messages by r e cogn i sing recognizing 

the occurred event in the received message and select, by using 
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the actual state, those actions attributed to the actual event-state 
combination. 

A f i rst pr e f e rr e d One disclosed embodiment of a d e v i c e 
accord i ng to includes the pr e s e nt i nvent i on i s charactoris e d i n that sa i d 
state engine editor is 
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being provided for attributing to each state-event 
combination, comprising said- the initial state, an action selected 
among said- the third sub-set._ In such a manner care is taken 
that a transition from the initial state will be performed. 

A s e cond pr e f e rr e d Another disclosed embodiment 
of a d e v i c e accord i ng to includes the pres e nt i nvent i on i s 
charact e r i s e d i n that sa i d actions belonging to said- the third set 
and said- the events of said- the second set afe- being 
predetermined.. In such a manner care is taken that for each 
action or each event there is an execution routine. 

Pr e f e r a b l v ln a disclosed embodiment, each 
diagram is- mav be identified by a description thereof and a 
reference to the object to which it belongs.. This enables a more 
flexible processing. 

A th i rd pr e f e rr e d ln another disclosed embodiment 
of a d e v i c e accord i ng to th e pr e s e nt i nv e nt i on is charact e r i s e d i n 
tha^each transition action of said- the third sub-set compris e s mav 
include a reference to an event of said- the second set, a source^ 
and a target state A as well as a reference to said- the diagram to 
which it belongs.. The presence of a target state enables the 
correct execution of the state transition. 

A pr e f e rr e d ln vet another embodiment of a method 
accord i ng to ± the present i nvent i on is character i sed i n that sa i d 
objects are classified by object types , e ach . Each object b ei ng 
may be identified by a definition and a description of the object 
type to which it belongs , and whoroin a . A plurality of event- 
state-action diagrams are- may be formed for each object , e ach . 
Each diagram corr e spond i ng mav correspond to one of saidthe 
object types^-said- . The monitoring may further 
compr i s i ng comprise a selection of at least one of said-the 
diagrams based on said- the object type.. This enables te-use of 
several diagrams for a- the same object. 

The i nvention The disclosed embodiments will now 

be described in more details with reference to the annexed 

drawings ill ustrat i ng a preferred embodim e nt of a dov i co and a 
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method according to th e pres e nt inv e nt i on. In th e drawings : A 
wherein the same reference character has been used to identify 
the same or analogous elements. 
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fiqwe Brief Description of the Drawings 

Fig, 1 shows a package state diagram using a 
standard ULM notation; 

fiqwe Fig. 2 shows schematically an example of the 
device according to the present i nv e nt i on a disclosed 
embodiment ; 

figwe Fig. 3 illustrates a finite state machine; 

figwe Fig. 4 illustrates an example of an event- 
state-action diagram; 

figur e 5 ill ustrat e s Figs. 5a-5d illustrate an example 
of an XML definition for an event-state-action diagram; 

f i guros Figs. 6 to 12 illustrate examples of editors 
for events, processing actions, timed actions, state diagrams, 
states and event z action-state diagrams respectively; 

figur e Fig. 13 illustrates a correlation in an entity 
relationship diagram; and 

f i guro Fig. 14 illustrates by means of a flowchart a 
method according to th e pr e s e nt inv e ntion a disclosed 
embodiment . 

I n th e draw i ngs a sam e r e f e renc e has b ee n a ll ott e d to a 
sam e or analogous ele m e nt. 

The present invont i on r o l a t o s Detailed Description 

The disclosed embodiments relate to a device and 
method for processing events, i n part i cula r for example, business 
process events, which occur in an arbitrary order.. Following the 
occurrence of an event, appropriate actions are triggered in real 
time, based on the current state of the business object on which 
the events apply.. The method Is- mav be based on a finite state 
machine design pattern.. From a macro point of view, the method 
is non-deterministic A i.e^ the same events will not necessarily 
lead to the same actions. .Moreover, the device allows dealing 
with changes in the business model, adding new objects, new 
state diagrams, new events, new states, new transitions,, and 
new actions as the situation evolves, which is usually the case in 
business environments. 
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A business process is usually described as a sequence of 
steps and actions, with a clear start and an end. _The output of one step 
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.provides the input for the next step._ Different 

methods have been developed to model business processes. 

Software tools have been developed to support the information 

flows related to business processes.. While traditionally, 

enterprise applications were developed to support the actions 

taken and information processed with a particular step in the 

process, it is only recently that methods and tools have been 

developed to support the whole process and the exchange of 

information between different enterprise applications-f . One 

example ^- is the transfer of information from the ordering system 

to the billing system and subsequently to the accounting 

system^ More specifically, workflow systems allow to modo l 

graphically modeling the different steps in the process and to 

connect connecting the output of one step with the input of the 

next step in the process.. These tools usually allow software 

coding to implement business logic and do perform data 

manipulations. 

The inconvenience with workflow systems is that 

the process flow hasmust always te-go through a predetermined 

path connecting subsequent steps to reach the end of the 

process in a sequential and deterministic way._ Each step in the 

process is not aware of the whole process.. A step receives input 

from its predecessor, and does some processing and provides 

input to its successor.. In reality, processes do not always work 

this way and workflows are not always the most natural way to 

represent business interactions between individuals, 

organ i sat i ons organizations and systems. 

The aim of business processes is to manipulate or 

transform a business object ( li k e an ord e r , such as, for example , a 

shipment, a parcel^ or any business transaction), which is handed over 

between different individuals, locations, organ i sat i ons organizations or 

systems until completion of the transaction.^ The business objects can 

be physical (e.g^ a parcel) or electronic (e.g^ an electronic message). 

The behaviou r behavior of such an object can be mod el led modeled with 

a state diagram or a finite state machine.. During its l if e cvc lo lifecvcle the 
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object will go through different states.. Actions are linked to a 
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.particular state of the object. As soon as an object 
arrives in a certain state, appropriate actions can be taken. 

The challenge is to maintain the consistency 
between the real physical state of the object and the virtual state 
as maintained by the information system and to take the actions 
linked to valid state transitions in an appropriate way. .During the 
li f e cvcl e lifecycle of the object, different agents on remote 
systems will publish events on the actual or current state of the 
object.. Due to the nature of the distributed network like the 
Internet, the published events do not always arrive on time at the 
central information system._ There may be a delay between the 
moment at which the event occurred and the moment it was 
received by the device.. Events may arrive in the wrong order and 
there may be many occurrences of the same event._ In other 
words, the generation of events is non-deterministic. 

In order to explain the problem to be solved, a real 
example from the parcel distribution industry will be taken. 
Packages are shipped from a source, corresponding to an initial 
state, to a destination, corresponding to a final state, within a 
certain time frame.. The shipment can be seen as a business 
transaction with a package as a business object to be monitored 
by the device according to the invention in order to ensure the 
proper completion of the business transaction and take 
appropriate actions where needed, like notifying the expeditor 
that the package will be late or notifying the recipient that the 
package has arrived.. During its transportation, the package will 
go through different states. 

An example of a package state diagram is shown in figur e 
Fig. 1. using the standard UML (Unified Mod elli ng Modelinq Language) 
notation for finite state machines._ The UML notation uses the pairs 
"event/action" on the transition arrow to describe the b e haviou r behavior 
of the objects, the event triggers the transition^ and the action results 
from it._ A package is "created^ for instance, when a tracking number 
has been generated by a 
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.shipping application and a label printed.. This 
package can still be cancelled, as shown by the transition 
"created -> cancelled^/! Typically, at the end of the day or at the 
end of a packaging cycle, the shipment will be confirmed, a 
consignment note or manifest will be printed with all the details of 
the packages to be shipped and a shipping file will eventually be 
sent to the courier.. The package is then in the state "Manifested" 
awaiting the courier to collect it._ Once the package has been 
collected it goes in the state "In Transit^ meaning that it is on 
its way._ The package might never arrive, arrive at a wrong 
destination (misrouting)^ or simply arrive late._ In this case, the 
package goes into an "In exception" state.. This might be a final 
state as the package may really be lost.. Normally the package 
will arrive at destination, which could be a drop-off point.. It will 
stay there until the final recipient will come and collect it. 

I n th e pr e sent inv e nt i on ln the disclosed 
embodiments, a state design pattern or finite state machine is 
used for mode l l i ng modeling the package delivery process or the 
b e h a v i our behavior of a package object.. If the method enables to 
fetio wfo I lowing the package delivery process flow in real time, the 
method can also easily feed different systems, which are 
involved in such a process for monitoring and controlling 
purposes.. For example-: 

a track and trace web site showing the current 

state of the package; 
-• a messaging system to notify a recipient 

indicating that a package can be collected; 
-• a billing system to register billing records; 
-• an alerting system to notify any exception in the 

process (package late or misrouted); 

a data warehouse for service level calculations. 
Such actions can be taken when a transition to a subsequent 
state occurs or after a time out within a certain stated , such as. 
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for example, package too long "In transit" or too long in 
^Delivered to location^ 



16 



The device and method according to the pres e nt 
invont i on disclosed embodiments have been developed to 
address problems of a real time supply chain event 
management, due to the specific nature of supply chain 
processes, but have been built in such a way as to solve real- 
time event-driven business process management problems, 
where the business object to be monitored and controlled can be 
mod el l e d modeled by a finite state machine. 

Figwe^ 2 shows schematically aft- one embodiment 
of a d e v i c e accord i ng to th e pres e nt invent i on. .^ The device 
comprises a processing member 1 connected to a memory 2. 
The latter is also connected to a state engine editor 1 1 
comprising an editing module 3, an XML formatter and a loader 
5._ The processing member has an input connected to a 
message bus 6 provided for transferring event-messages.. The 
processing member comprises an event-receiving element 7 
connected to a state engine processor 8., An output of the state 
engine processor 8 is connected to an action dispatcher 10 and 
a further output of the state engine processor is connected to a 
timed action generator 9, having a trigger signal output 
connected to the action dispatcher. 

The state engine editor 1 1 is provided to create 

event-state^action diagrams, which are related to object types. 

The device allows t o o p e r a t e operation with several object types 

and to cr e ate creation of a diagram for each object type.. It is 

also possible to create several event-state-action diagrams per 

object type._ The processing member is provided to create, even 

on runtime, actual event-state-action diagrams for effective real 

objects and to process a plurality of diagrams in real time._ Each 

running diagram bemg-js_associated te- with one running object of 

for which the actual state is monitored. 

The creation of such an event-state-action diagram is 

roa li s e d realized by the state engine editor 11, which has an input for 

receiving object data identifying the object to be processed as well as 

the initial and final state for that object.^ Once the event-state-action 
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diagram is created for the object to be considered, it is stored in the 
memory 2. 
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_When the diagram is stored in the memory it can 
be retrieved by the processing member 1 in order to be 
processed.. The processing member will react on event- 
messages circulating on the message bus 6. 

The state engine processor 8 is built on the concept 
of a finite state machine. .This concept is illustrated with 
reference to an example shown in f i qur e Fig. 3. .The finite state 
machine of fiqwe Fig. 3 comprises four states A, B, C and D of 
which A is the initial state and D the final state, C and B being 
intermediate states. _The states are grouped in a first set 
grouping a finite number of states._ A transition from one state to 
another is caused by an event._ It should however be noted that 
not each event will cause a transition.. Different events may 
cause the same transition, in case a different behaviou r behavior 
(different actions) is desired based on the triggering event._ One 
event can only cause one transition from a source state to a 
target state._ When an event occurs, eventually a 1 transition is 
made and actions are triggered.. The events are grouped in a 
second set grouping a finite number of events.. The actions are 
grouped in a third set grouping a finite number of actions.. The 
third set comprises a first sub-set of processing actions, such as 
for example sending a receipt message.. The third set further 
comprises a second sub-set of timed actions, which are actually 
timers triggering an actionfs} or actions upon expiration of a 
predetermined time period.. When the state of an object 
changes, all running timers (or timed actions) of this object are 
cancelled.. Finally the third set comprises a third sub-set of 
transition actions triggering a transition from the actual state to 
the target state. 

Figwe. 4 shows an event-state-action diagram based on 
the example of figwe Fig. 3. _This model allows to d e f i n e , mod i fy, 
mon i to r defining, modifying, monitoring, and eofrtfot controlling business 
processes in a very efficient way._ The method enables to e asi l y cr e at e 
easy creation of new state machines, add or mod i fy adding or modifying 

states, events A and actions.^ Based on the received object data 
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identifying the object, the event-state-action diagram is formed by the 
state engine editor 11._ For this purpose the state engine editor 11 uses 
the matrix set-up illustrated 
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.in figur e Fig. 4. .The received object data comprise 
the events, selected among the second set and the states 
selected among the first set.. The events are organ i s e d organized 
row-wise and the states column-wise.. Consequently matrix 
positions are created, which each time corresponds to a state- 
event combination.. The state engine editor is further provided for 
attributing to at least one state-event combination at least one of 
said actions of the third set._ The attribution of the actions is-ba^ 
inter alia, determined by the initial and final state of the object, by 
the path to be traveled from the initial to the final state A as well as 
by the events, which could occur. 

The use of the matrix set-up enables a flexible 
build-up of the diagram because the number of rows and 
columns is as if to say unlimited. .Modifications are implemented 
by adding or deleting rows or columns or by modifying the 
attributed events.. Moreover the diagram makes it possible to 
treat incoming events in an unrelated order. 

In the example shown in f i gur e s Figs. 3 and 4, it can 
be seen how the state engine would behave in case it misses an 
event. _A normal flow of events could be state A to state C with 
event a and then to state D with event c. Suppose that state A is 
the actual state and that event a is missed.. Upon receipt of 
event c, the object will move to state D._ The same actions 
(actions 4 and 5) can be taken as if they would originate from 
state C._ An additional action (action 6) is then taken, which could 
be for instance a warning message to notify that event a has 
been missed.. If the relevant object later receives a notification of 
event a, it will not take the same actions associated with the 
transition, i.e^ state A to state C, as they are not relevant in the 
context of state D, except for action 1 . 

It should also be noted in the example that both, 
event c and event d, will allow a transition from state A to state D, 
but the associated actions are different. .Therefore they are 
considered as two different transitions within the same state 
diagram. 
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An example of an end use of such an application is in a 
package delivery business. .In such a business the state of a package 
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_(the relevant object) may change before the state 
engine receives or can react on an event. BtQt For example , the 
change of the state of a package to "ready for pick up" is an 
event, which typically triggers an action to notify the customer. 
However, if before such a notice is sent, the state of the package 
changes from "Ready for pick-up" to "Delivered" then the state 
engine determines not to send such a notice.. Thus, the state 
engine responded to the same event differently based on the 
actual state of the package. 

The state engine editor is preferably formed by a graphical 
user interface (GUI) for creating and modifying events-states-actions 
diagrams. Jt preferably generates an XML description of the diagram, 
which can then be loaded in the memory 2. F i gur e Fig. 5 shows an XML 
definition for the events-states-actions diagrams. _The specification of 
this XML file can be considered as a "Business Process State Engine 
Language" or BPSEL, which has similarities with other Business 
Modeling language, but is much simpler.. As can be seen in figwe Fig. 5, 
the objects are classified by object types. _This classification enables te 
a ttr i but e attributing specific diagrams to each object type._ For each 
object type a definition is stored in the memory._ A unique reference 
identifier is attributed to each object type, as well as a name._ A 
description of the object types is also stored ._ All these data enable a 
uniform definition of the object, thus leading to an efficient processing. 
As can be further seen in figwe Fig. 5 a definition is also stored for the 
diagram. _The diagram, the states, the events, the actions, all have a 
unique reference identifier, a name and a description.. To each diagram 
there is also attributed a reference of the object type on which the 
diagram applies.. To each state, there is also attributed a reference of 
the diagram, to which the state belongs.. The timed actions all have a 
predetermined time period indicating at which time they should trigger. 
The transition actions have a reference to a triggering event, the source 
state and diagram as well as a 



23 



.reference to the target state to be reached upon 
occurrence of the transition. 

A further distinction can be made between two types of 

actions-^ 

. A first type is generic actions , which . Generic actions 
can be invoked for any type of object.^ The code logic of these actions 
uses only the parameters of the triggering event, and not a logic specific 
to the object embodied in the events 

. A second type is object specific actionsi-wfrteh . Object 
specific actions can only be invoked from state machines relating to the 
same object type as the embodied object. 

_The implementation of these methods may use 
logic, which is specific to the type of the embodied object.. An 
example of such an object specific action is an action referring to 
a tracking number of a parcel. 

For forming the diagrams, the state engine editor will use 
the editors of which an example is given in th e f i gures Figs. 6 tel2r to 12. 
The state engine editor allows to defin e defining and modif ymodifying all 
entities of the state machine. Figure Fig. 6 shows the basic screen of the 
editor as it appears in a standard HTML browser. 

_On the top there are three selections-: 

• definitions of basic entities, object types, events, 

actions, timed actions, state diagrams and 
states; 

• definition of diagrams, for each state and for 

each event, transitions and actions to be 
performed; 

• repository, save and load XML schema's in the 

editor, and load the active schema into the 
memory. 

The screen layouts are self explanatory and directly in line 
with the definition of the XML file in tigwe Fig. 5. J"he object type screen 
is simply a declaration, and the indication of the object classes and/or 
databases of the application server.^ The designer can select an object 
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type on the basis of the received object data and attribute a name and a 
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.description to the selected object type.. The icons 
"new^ "update/ 1 and "delete" provide to the designer the 
possibility either to create a new object type or to update or 
amend existing object types._ A box is further provided for 
introducing a predetermined amount of names and associated 
descriptions.. As is indicated in th e f i gur e s Figs. 6 to 12, figwe Fig. 
6 relates to object types, tigwe Fig. 7 to events, figwe Fig. 8 to 
actions, f i gur e Fig. 9 to timed actions, f i guro Fig. 10 to state 
diagrams, figur e Fig. 1 1 to states^ and figwe -Fig. 12 to diagrams. 

It should be noted that events and object types are 
closely linked to each other. .Event messages will always 
embody the associated object and will be applied only to the 
running state machine diagrams associated with the embodied 
object.. The name of the event and the embodied object type 
serve as interface specification between the process designers 
and the designers of the messaging system, transporting the 
event messages and/or the object classes and/or databases of 
the application server.. The name of the action serves as 
interface specification between the process designer and the 
designer of the method implementing the action and running on 
the application server.. The object type is not mandatory for 
actions.. If the object type is not specified, the action can be 
applicable on all state machines, for all type of objects. 

Like actions, timed actions can be generic for all 
object types or specific to one object type. _A timed action 
specifies a timeout variable and one or more generic or object 
type specific actions, which will be invoked upon expiration of the 
timer.. The action list allows multiple selections. 

The state diagram screen in the entities menu is for the 
declaration of the state diagram names and the link to the related object 
type. _These declarations are needed to create the states.^ The same 
object type may have different state diagrams.^ The instantiation of an 
object may also have different state machines running in parallel, but not 



26 



_necessarily._ This will depend on the events 
causing the transitions.. The state machines, executing actions 
for the same object, may have different triggering events. 
However, the different running diagrams relating to a same 
object shall be different from each other. 

For each diagram selected in the upper left table of 
f i gur e Fig. 12, all possible states are displayed in the lower left 
table._ For the selected source state, one can see all existing 
triggering events on which the state machine needs to act upon. 
It should be noted that not all possible events need to be 
configured and that a state transition is not always mandatory. 
The target state may be the same as the source state._ In the 
upper right panel (Transition Editor) one can create, modify or 
delete transition by specifying, for each origin state, the triggering 
event, the target state and one or more generic or object specific 
actions and/or timed actions.. The actions lists allow multiple 
selections. 

The device according to the pr e s e nt 
i nv e nt i on disclosed embodiments is provided for processing a 
plurality of diagrams relating to a same object and also for 
processing a plurality of diagrams for a plurality of objects.. The 
use of object types will enable the selection of a diagram, since 
the incoming event-message will comprise an indication of the 
object type. 

Figure,, 13 illustrates an Entity-Relationship Diagram (ERD) 

for processing an event-state-action diagram. _The ERD comprises a 

first part, which forms the memory content and a second part formed by 

the runtime and historical data._ From this ERD it can be derived that an 

event (40) is always related to one object type (41^ In other words, if 

there is no object type considered, no events can happen._ A state 

diagram definition (42) is always related to one object type (41) and has 

at least one state (43) by default, which is "none" and corresponds to the 

initial state of the finite state machine.^ An object type (41) may have 

more than one state diagram definition (42)r._ So A for example^ in the 

case of a parcel, one state diagram could be related to the billing of the 
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object and another state diagram could be related to the travel path of 
the 
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_parcel._ A state (43) is always related to a state 
diagram definition (42)^ An action (44) is optionally related to 
one object type (41 ^ Without object type reference, the action 
(44) is considered as a generic action, which can be used in all 
state diagrams, regardless of the object type.. A timed action (45) 
is optionally related to one object type (41)^ Without object type 
reference, the timed action is considered as a generic action, 
which can be used in all state diagrams, regardless of the object 
type._ A timed action (45) is linked to at least one action (44)r. 
The state engine editor (3) will ensure consistency of object 
types (41) between timed actions (45) and actions (44)^ A 
transition (46) is always related to one state diagram definition 
(42), and is always character i sod characterized by one triggering 
event, one source state A and one target state, which can be the 
same as the source state.. Each record in the transition table 
corresponds to one cell of the event-state-action diagram as 
described in f i gur e Fig. 5. .A transition may have none or several 
associated actions and timed actions. 

The part formed by the runtime and historical data 
is not in the XML definition, but is used by the state engine to 
maintain the instances of the running state machine and log their 
associated events, state changes, actions,, and timed actions: 

• Object (50) 

• Running State Diagram (51) 

• Event History (52) 

• State History (53) 

• Action History (54) 

• Timed Action History (55) 

The relations between these tables mirror the definition 
tables kept in the memory of the device. _One can see that one object 
may have several running state diagrams (51; each corresponding to a 
different state machine).^ A running state diagram has always one 
current state, corresponding to the possible states linked to the state 
diagram definition.^ An event is always related to one object, which is 
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embodied in 
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_the event._ State history, action history, timed 
action history records are always related to one running state 
diagram and one instance of a triggering event (Event History 
table)._ In case an object type should have different state 
diagrams, the same triggering event may be applicable to 
different running state diagrams and hence generating different 
transitions which will lead to different records in the state, action^ 
and timed action history tables, all linked to the same triggering 
event in the event history table. 

The device according to the pr e sent 
i nv e nt i on disclosed embodiments allows alteration of existing 
state diagrams, even for state machines with running instances. 
In order to support change management, a version control 
mechanism has been introduced.. In case a state diagram has 
changed, new reference identifiers are generated for the entities 
where needed, so that running instances are still linked to a 
previous version and can continue to function normally until a 
final state is reached New instances will be linked to the new 
version of the diagram. 
Industrial Applicability 

The operation of the device as well as the 
application of the method will now be further described with 
reference to th e f i gur e s Fiqs. 13 and 14. JFor the operation of the 
device, three elements need to be known and supplied to the 
device-: 

at least one object to be managed by the device 
(known by its type and unique identifier); 
the events to which the device will subscribe 
(known by their name and embodied objects); 
-» the processing actions to be executed by the 
device according to the rules defined in the 
editor (known by their name and type, generic 
or object specific). 
Once these elements are supplied to the device, the event 



31 



state-action diagram^ or diagrams is ( or are) formed A and the 
processing of the events can start._ For forming the event-state-action 
diagram^ or diagrams, use is made of the state diagram definition 42. 
The matrix framework of the diagram is 
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jDuilt up with the supplied events and the different 
states to be occupied by the embodied object during its traveling 
from the initial to the final state.. At those state-event 
combinations where actions are required, the processing actions 
are attributed.. The state diagram definition 42 is only used 
during the diagram build-up._ Thereafter the running state 
diagram 51 is used upon processing of the events and actions. 

Upon receipt (20) of an event-message traveling on the 
message bus (6; figwe Fig. 2) the processing member will save (21) the 
event present in the event-message into the event history table (52) with 

a link to the embodied object. The embodied object is 

r e cogn i s e d recognized by a na l ys i ng analyzing the event-message, which 
comprises an identifier for the embodied object._ The object table (50) is 
filled with the embodied objects, so that whenever an event message 
with an embodied object occurs on the message bus, there is always a 
valid record in the object table for the embodied object._ If the received 
event-message comprises an object, which is not present in the object 
table, an error message will be generated.. The device will process (22) A 
by means of a loop A the received event for each state diagram definition 
record linked to the object type of the embodied object._ In the loop there 
will be checked (23) A in the running state diagram table-i f, whether there 
is already a record with a reference to the current state diagram 
definition of the loop and a reference to the embodied object._ If no 
record is found, the transition table is searched (24) to find whether there 
is a record with a reference to the current state diagram definition of the 
loop A and a reference to the event being processed by the device and a 
reference to the source state "NoneV^ If such a record is found, a new 
record is created (25) in the table running state diagram, with a link to the 
embodied object, a link to the current state diagram definition of the loop A 
and a link (the current state) to the state "None" which is linked to the 
same state diagram definition^ If such a transition from "None" with the 
processed event is not found, the device will loop (30) to the next state 
diagram definition.. In other words 
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^during step 24 there is checked if a new running 
state diagram has to be created for the embodied object. 

Once the state diagram for the embodied object is 
found, the current state is also rocognisod recognized since the 
device m e mor i s e s memorizes for each running diagram, the 
actual state thereof The actual state in combination with the 
received event indicates a location in the matrix forming the 
diagram.. As described horo b o foro above . at this matrix location 
the actions to be executed, if any, are stored.. If a transition 
action has to be executed, the device will search (26) in the 
transition table in order to find a record with a reference to the 
current state diagram definition of the loop and, as triggering 
event, a reference to the processed event and, as source state, a 
reference to the same state as the current state of the running 
state diagram corresponding to the current state diagram 
definition of the loop and having a reference to the embodied 
object.. Such a transition record will always be unique, per 
definition of the deterministic nature of the finite state machine at 
design time. 

If such transition record is found, the device will process 
one or more of the three action types, depending on the actions 
indicated at the addressed matrix location 

— . First, state change and cancel related open timers, if 
the target state is different from the source state (27)f 

— . Second, processing actions, which will execute the 
code of the related pre-determined actions (28) by means of the action 
dispatcher (10, figwe- Fig. 2). For this purpose, the action dispatcher 
comprises for each action of the third set an execution routine provided 
for controlling said- the execution of said- the retrieved action(s)i 

— or actions. Third, timed actions, which will initiate the 

timers (29)r 

^_Every action is recorded in respectively the state, 
action and time action history tables for further reference and 
analysis. 
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The device also comprises a scheduler (9, figuro Fig. 2), 
which will automatically execute the processing actions linked to the 
timed actions after expiration of the timer as specified in the timed 
action table. 
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Abstract of the Disclosure 
A d e v i c o and a mothod for proc e ss i ng e v e nts and act i ons. 



A Device and a Method For Processing Events and Actions 

A device operating as a finite state machine and provided for processing events and 
actions relating to at least one object to be trav e ll e d moved between an initial and a 
final state , sa i d . The device comprising a processing member connected to a 
memorw-said . The initial and final stat o bo i ng states are integrated into at least one 
event-state-action diagram defining said finite state machines-sate . The event-state- 
action diagram h a v i ng has a matrix structure where each event-state combination 
forms a matrix position.. Actions formed by transitions, processing actions^ and timed 
actions,, are stored at the matrix positions. Sate The processing member bo i ng is 
further provided for retrieving satethe actions and for supplying satethe retrieved 
actions to an action dispatcher in order to execute satethe actions , sa i d . The action 
dispatcher compr i s i ng comprises, for each action of said third set, an execution 
routine provided for controlling satethe execution of satethe action. 

Figur e 2 
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